אני בונה אתר בOOP, ויש לי הרבה פונקציות שבתכל'ס המשתמש לא נוגע בהם, רק המתכנת.
עד עכשיו עשיתי בדיוקת לארגומנטים וכולי, אבל רציתי לשאול אתכם: אם גם ככה אני יודע איך לכתוב, יש צורך בכלל לבדוק תקינויות בקטעים כאלו?
נניח יש לי מחלקה יורשת מ SQL, ובקונסטרקט יש לי את ההתחברות למסד, אם אני יודע מה הארגומנטים, ושההתחברות טובה, יש צורך בכלל לבדוק את זה?
דוגמא יותר טובה: מחלקה ליצירת טופס, היא מקבלת בקונסטרט METHOD למשל, זה הכרחי להכניס אבל אני בתור המתכנת יודע את זה, והמשתמש לא מתערב פה.
לבדוק תקינות או לא ומה יותר יעיל?
תודה רבה לעוזרים, מקווה שהבהרתי את עצמי :)
11 תשובות
ענה
כשאתה אומרת לבדוק, למה אתה מתכוון? יש הרבה סוגי בדיקות,
אם אתה מדבר על רמת האבטחה, אז כל דבר שמתקבל מהמשתמש, כן דורש סינון הנתונים
ענה
אני מדבר על פונקציה שדורשת ערך מארגומנט למשל, אז צריך לבדוק האם ניתן ערך במידה והמתכנת כבר יודע שצריך את הערך?
אני לא בטוח למה הכוונה מאחר וPHP או כל שפה יחייבו אותך לשים ערך באותה פונקציה,
הכוונה האם הערך מאותו הסוג שאתה צריך?
אם למשתמש אין דרך לקבוע את זה אלא רק המערכת, אז לא,
אם המשתנה הוא לא מסוג פרימיטיב, אז אפשר לעשות הינטינג כמו array $some_array
וזה יחייב שיהיה שם מערך, כנ"ל לגבי אובייקטים
לפעמים כן ולפעמים לא,
אתה יוצא מנקודת הנחה שאתה בתור מתכנת לא תעשה טעות,
ועדיין לא הסברת מה הכוונה בבדיקה?
בדיקה של אבטחה / תקינות המשנה מה אתה בודק?
בדיקה של תקינות בעיקר, וכן, בהנחה שהמתכנת לא עושה טעויות, יש צורך בכלל לעשות בדיקות בפונקציה או שזה מבזבז משאבים, זמן וקוד?
תקינות של מה?
תפרסם פה פונקציה לדוגמא שאתה לא בטוח לגביה,
אחרת אין לי תשובה חד משמעית, "תקינות" זה משהו מאוד רחב
הנה דוגמא לפונקציה במחלקת validator שלי:
public function __construct($met) {
if($met != 'get' && $met != 'post')
throw new Exception('Bad method in validation!');
$this->met = $met;
}
השיטה חייבת להיות או גט או פוסט, משום שזה משפיע על הפונקציות האחרות, אבל הרי אני בתור המתכנת שמכיר את הקוד יודע שחייב אחד מהם, אז יש בכלל צורך לבדוק האם זה אחד מהם?
ענה
iiddaannyy
ב
22 ליולי 2012
#
כדאי.
במקרה שהצגת כאן ^, זה כדאי כי הרעיון מאחורי תמ"ע (OOP) הוא בעצם לחלק את הקוד לחלקים.
מה הכוונה? הכוונה היא שהמחלקה שיוצרת טופס היא עצמאית, היא לא קשורה לשאר הקוד. זה אומר שאתה יכול לקחת אותה ולשים אותה בפרויקטים אחרים בלי שום בעיה, כי היא עצמאית ולא תלויה בשאר הקוד.
כל זה אומר בעצם שאתה כן צריך לוודא שהנתונים שהגיעו אכן תקינים. אסור לך לסמוך על שאר הקוד, כי המחלקה היא חלק בפני עצמו שלא קשור ולא מסתמך על שאר הקוד.
וחוץ מזה - זה תמיד טוב. כשתרצה לשנות משהו ותכתוב ger במקום get בטעות, אתה תעלה על זה בשניה.
ענה
אני לא בטוח ששמת לב, אבל התנאי שלך תמיד יחזיר שקר :S
במקום && (AND) תשנה ל || (OR) או שתעתיק את זה:
if($met != 'get' || $met != 'post')
throw new Exception('Bad method in validation!');
$this->met = $met;
}
ענה
באופן כללי לבדוק את הארגומנטים עצמם אין צורך, אבל לטפל בשגיאות כדאי, כאשר רמת הפירוט ותפיסת השגיאות משתנה בהתאם למערכת שאתה מפתח.
אם אתה מפתח פריימוורק או ספריה שאנשים אחרים אמורים להשתמש בה בלי לדעתי איך היא מורכבת מבפנים - אתה צריך לכתוב את הקוד ככה, שהסיכוי שישלחו לך ארגומנטים לא נכונים יהיה מזערי. לדוגמה: שם של פרמטר connectioString אמור להגיד למפתח שזה מחרוזת ולא משהו אחר. בנוסף php מאפשרת לך לרשום מאיזה סוג אמור להיות הארגומנט (type hinting).
אין צורך לבדוק שקיבלת מחרוזת באורך יותר מאפס ולא מערך, אבל כדאי לבדוק שההתחברות למסד הצליחה ואם לא - להציג הודעת שגיאה שאומרת למפתח לבדוק את תקינות ה-connection string.
כשאתה כותב משהו אחר שלא אמור לתפקד בתור קופסה שחורה אלה המפתח יודע ומכיר את מבנה הפונקציות שהוא עומד להשתמש בהם - אין ממש מה לבדוק. בזמן הדיבאג המפתח יבין מה הולך ויתקן את מה שצריך במידה וצריך.
כשאתה כותב ב-OOP המטרה שלך היא כנראה לקבל את התוצאה הראשונה. חלקים שאפשר להישתמש בהם שוב ושבו ולא לדעת מה קורה בפנים. ככה שההנחה היא לכתוב ככה שלמתכנת יהיה יותר קשה לטעות ולדווח על שגיאות.
והכי חשוב - במידה ויש שגיאה בחיבור למסד, לא רק לכתוב שהחיבור לא הצליח, אלה גם לתת איזשהו הסבר ודרכי פעולה לתיקון.
The database connection wasn't established, please check the provided connection string.
or
The database connection could not be established, reason: Mysql Error 00010 the table blabla does not exist ...